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ABSTRACT 



This thesis presents an integer programming model to help the Navy develop 
long-range shipbuilding plans. The model is of a general nature, but is proposed 
specifically as a decision aid for the developers of the Navy’s Extended Planning 
Annex (EPA). The EPA sets forth planned ship purchases five to 20 years in the 
future. It is currently produced with a mainly manual process that takes weeks at a 
time, hence it is extremely difficult for the EPA planners to respond quickly to 
changes in the given data and assumptions. The optimization model suggests 
delivery dates for new ships, based on given budgets and requirements, and 
accounts for such complexities as the extra costs of building a leadship or of 
resuming construction after a production break. The model has been formulated 
with the General Algebraic Modeling System (GAMS) and effectively solved with 
two commercial optimization packages. It performs fast enough to allow the planner 
to make several “what if’ runs in the course of developing the EPA. 
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I. BACKGROUND 



This research is an attempt to assist the Navy in planning ship purchases five to 
20 years in the future. An optimization model is developed which will produce an 
initial ship purchase plan. This proposed plan can then be used as a starting point 
for developing the actual plan set forth in the Extended Planning Annex. 

A. EXTENDED PLANNING ANNEX (EPA) 

The Extended Planning Annex (EPA) is an annex to the Five Year Defense 
Program which shows the planned status of the Navy and Marine Corps assets in 
the years following those covered by the Five Year Defense Program. It is a “best 
guess” of what the Navy will consist of in those years far in the future. It is not an 
approved expenditures list, but a long range plan which can be updated or changed 
as the budget, the current status of the Navy, or its requirements change. The basic 
concept behind the EPA is an affordability analysis of future programs. 

B . HOW THE EPA IS USED 

Many decision makers in the Department of the Navy use the EPA in preparing 
their own long range plans. The EPA shows the projected status of the Navy’s 
ships, aircraft, and personnel based on the Navy’s analysts’ expectation of what will 
be affordable. Many decisions concerning today’s assets invariably depend on what 
kinds of assets are expected to be available in the future. For example, if a new 
carrier is planned in the EPA to come on line in seven years, the personnel who will 
be rotating at that time will have to decide whether they want to serve on that carrier, 
and the detailers will be penciling in people to be the high ranking officers. If the 
new carrier comes on line as scheduled in the EPA the escort ships must be ready to 
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proceed with the new carrier when it goes out to sea. Also, an older carrier may be 
sent to the yards for an overhaul based on when the new carrier comes on the line to 
take its place. This is of course only one example, many others could be cited. 

C. HOW THE EPA IS CURRENTLY DEVELOPED 

The current procedure for developing the EPA involves a member of the Chief 
of Naval Operation’s OP-81 staff (currently LCDR M. J. Zurey) spending a great 
amount of time trying to develop a ship purchase schedule which will be affordable 
and maintain desired fleet characteristics. Some of the scheduling is relatively easy 
since the decision is mandated by other documents (e.g., the number of ballistic 
missile submarines is included in treaties). Most decisions have more latitude and are 
made through a manual trial and error process. Many considerations must be taken 
into account, and examples of these include: 

1 . When are ships going to be retiring and thus require replacement? 

2. When are ships going to be built to replace retiring ships? 

3 . How much money in each year is left over after the required ship purchases? 

4. Is it better to build a new ship or extend the life of the ships coming up on 
retirement through the Ship Life Extension Program? 

5. Is there enough money to build several ships all of which need to be 
delivered in the same year? If not, when should each be built? 

6. Should the production line for one type of ship be stopped in order to 
release funds to build another type ship? 

7 . Will there be enough personnel to man the ships which are being built? 

8 . Will the budget for ship construction increase or decrease, and by how 
much? 

9. If a ship retires without a replacement, will the Navy be able to meet the 
national force requirements with the remaining ships? 
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This is not an exhaustive list of questions and important factors. Fiscal 
considerations are complex. Ships are not paid for when they are delivered, but 
require installments years ahead of delivery, and lead ships do not cost the same as a 
typical ship off the production line. Also, one must remember that allocations of 
millions or billions of dollars are being planned for use five to twenty years in the 
future. The need to satisfy many conditions and to keep track of expenditures for 
several years suggests the use of a computer rather than a manual procedure. The 
need to make good decisions about how to best allocate money suggests the use of 
an optimization or simulation model. Optimization or simulation techniques can then 
be used to assist the decision maker in choosing the best values for the decision 
variables. Reference 1 describes simulation models as “strategy evaluation models” 
and optimization models as “strategy generation models.” Thus, in order to use a 
simulation model, every possible combination of purchase plans (or at least every 
sensible plan) must be generated ahead of time. Each plan is evaluated by the model 
and the best plan selected. This is simply not feasible with the number of possible 
alternatives available. This is the reason for choosing an optimization model. 

D. THE NEED FOR A COMPUTER MODEL 

The current long range plan is developed manually by an analyst at OP-81. One 
plan generally requires weeks to prepare. If there is a change either in the budget or 
the threat scenario, the plan must be redeveloped from the beginning. In order to 
reduce the time required to develop long range plans LCDR Zurey requested that 
the Naval Postgraduate School’s Operations Research Department conduct research 
on how to computerize the process. As part of the computerization, a model must 
be developed. The main purpose of this study is the development of an optimization 
model to aid analysts in preparing long range plans. 
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II. OPTIMIZATION MODEL 



The model is presented in two versions: conceptual and implementation. The 
conceptual version of the model is designed for ease of presentation, to provide a 
rough idea of the model’s capability before presenting the more complicated version 
that was actually implemented. Both models use “elastic” [Ref. 2] or “soft” [Ref. 3: 
pp. 36-37] constraints and a penalty function associated with the elastic variables as a 
means for finding a highly desirable, if not classically “optimal,” long range plan. 
Elastic variables allow constraints to be violated at a cost. They allow the model to 
reflect the common managerial practice of violating some constraints in order to 
satisfy others or to improve the objective function. To accomplish this, two elastic 
variables are added to each equality constraint, and one elastic variable to each 
inequality constraint. Elastic variables have penalties as their coefficients in the 
objective functions. They are restricted to be nonnegative and will take on positive 
values when the corresponding constraints are violated. One advantage of elastic 
constraints is the ease of obtaining an initial feasible solution to the model. 
Following the notation originated in Brown and Graves [Ref. 2], relational 
operators with a small circle on the top indicate elastic constraints. This notation 
eliminates the need for explicitly displaying the actual elastic variables in the model, 
thereby making it easier to read. (The notation also reflects Brown and Gaves’ 
computional practice in their X- System solver [Ref. 4] of treating elastic variables 
implicitly.) 
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A. CONSIDERATIONS 

To be useful, the model must be realistic and flexible. To be flexible, a model 
should allow the user to perform “what if’ type of analysis (e.g., “What happens to 
the plan if the projected budget goes down instead of up?”, or “What happens to the 
plan if we need another carrier?”). To be realistic, a model must include the 
following features: 

1 . A production line for a ship type may stop and be restarted. This happens 
when funds must be transferred from one ship type to another. In general, 
there is also a cost associated with restarting a production line. 

2. Allow for bounds on the number of ships being constructed in a given year. 
Each ship type has an upper bound and a lower bound on the number that can 
be constructed per year, if any are constructed. There is also an overall bound 
on the number of ships which may be under construction at any one time. 

3 . Payments for a ship are required long before the ship is delivered. Some ships 
require payments in multiple years prior to delivery. Some ships require 
expenditures after delivery, e.g., for outfitting. Each ship type has its own 
payment schedule. 

4. Leadships require payment structures that are different from the follow-on 
ships. A leadship costs more and takes longer to build. Additionally, the 
leadship is delivered in a year by itself, with a year (or perhaps two years) 
enforced delay before any more ships of that type are delivered. 



B . CONCEPTUAL MODEL 
1 . Index Use 
i Ship type 


{ CV, CGN, FFG, ... } 


d 


Calender year of ship delivery 


{ 1990, 1991, 1992, ... } 


P 


Calender year of payment 


{ 1990, 1991, 1992, ... } 


k 


Ship’s production status 


{ typical, resumption, leadship } 


A “resumption” status indicates that this is the first ship of its type to be 
constructed following a break in the production line. All the cost of restarting the 
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production line is added to this ship. The “leadship” status is reserved for the very 
first ship of a given type. All other ships are given the status of “typical.” All 
inappropriate index combinations are screened out. 

2. Given Data 

ship quantity data 

need w Quantity of ship type i needed in year d. 

have^ Quantity of ship type / that are in year 0 inventory and will still be in 
operation in year d. 

getting/^ Quantity of ship type i that are currently under construction and will 
become available in year d. 

The net demand for ship type i up to year d is derived as follows: 

netdem/rf = need^ - have^ - Xgetting /d . 

d'<d 

It should be emphasized that the number of ships needed in future years is an 
input to this model. These needs are determined by other analysts and 
communicated to the OP-81 officer in charge of scheduling the ship purchases. 
fiscal data 

c ikdp Cost in year p for each ship of type i and status k delivered in year d. 

budget^ Money available to purchase ships in year p. 

Fiscal data is generally given in units of millions or hundreds of millions 
of constant year dollars. Defining the cost parameter with two time subscripts (d and 
p) allows for greater flexibility in modeling ship costs. For example, if p < d then 
the cost is due to construction, and if p > d then the cost is due to outfitting. The 
actual method for inputting the cost is much easier than filling in the four 
dimensional array c ikdp , as shown in the Appendix. 
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production limitations data 

lag ; Number of years required to construct a ship of type i.. 

upbnd jd Upper bound on quantity of ship type i that can be delivered in year d. 

lwbnd-^ Lower bound on quantity of ship type i that can be delivered in year d 
if any are delivered. 

sybnd p Upper bound on total number of ships that can be under construction 
in year p. 

policy data 

Relative penalties for elastic variables associated with elastic constraints. The 
value assigned to these penalties has a profound influence on the solution. The 
method used in this research is described in Chapter III. 

3 . Decision Variables 

The decision variables in the conceptual model are: 

Xikd Number of ships of type i and status k to be delivered in year d. 

Elastic variables associated with elastic constraints also exist, but are not 
explicitly referred to as decision variables. The value of Xikd. for £ = “resumption” 
or “leadship” must be binary, while for k - “typical” it is a general integer. 

4. Formulation 

The conceptual formulation minimizes the total penalty cost associated with 
violation of the elastic constraints to be described below. This type of planning 
usually involves so many conflicting constraints that it is generally impossible to 
satisfy all the constraints inelastically. 

MIN: X PENALTIES 

ST: 1) DEMAND/^: [Ensure that the number of type i ships 

delivered during or prior to year d meets the net demand.] 

X X Xikd' - netdem/d , V i,d 
d'<d k 
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2) FISCAL;,: [Observe budget in year p.] 

. 'ZcikdpXikd = budget;, , V p 
ikd 

3) CONSTRUCT;,: [Observe limit on the number of ships 
under construction in year p.] 

X X *ikd ^ sybndp , V p 
ik 0<d-p<lagi 

4) Ensure the total number of ship type i delivered in year d 
is e [0, lwbnd id, ... , upbnd/rf }. 

5) For new ship types, force the leadship to be delivered before 
any typical ships. 

6) Force a resumption unit to be delivered following a 
production break. 

The first three sets of constraints are relatively easy to handle. The logical 
constraints (4) - (6) require further development. In particular, constraints (5) and 
(6) involve non-convex costs, and therefore a linear programming optimizer will 
tend to violate them. Constraint (4) requires using general integer decision variables 
with a range of values from a disjoint set of integers (e.g., {0, 3, 4, 5 }). Like the 
non-convex costs, this condition causes computational difficulty in practice. 

C . IMPLEMENTATION MODEL 
1 . Decision Variables 

The implemented version of the model uses binary decision variables 
exclusively. This choice is more amenable than general integer variables to most 
solvers and it proves advantageous when constructing logical constraints. 
However, it increases the number of decision variables. The conceptual model uses 
index k to distinguish ship status, “typical”, “resumption”, or “leadship”. The 
implemented version instead uses three separate variables for this purpose. 



Additionally, a new index j is used to indicate the quantity ordered for typical ships. 
The new binary variables and their meaning are: 

XT idj =1 <=> j = number of typical ships of type i to be delivered in year d. 
XR id = 1 <=> A resumption ship of type i is to be delivered in year d. 

XL id =1 <=> A leadship of type i is to be delivered in year d. 

Since the index k has been dropped, the cost coefficients are similarly 
redefined: 

ct^ Cost in year p for each typical ship of type i delivered in year d. 

CT idp Cost in year p for each resumption ship of type i delivered in year d. 
cl Cost in year p for each leadship of type i delivered in year d. 

All inappropriate index combinations are screened out prior to sending the 
model to the solver. The binary variables with index j are related to the original 
variables as follows: 

Xid'typical' - X^XT/^/y 
j 

A binary variable must be defined for each possible positive value of Xid’typical ' . 

To allow at most one of the new binary variables to take the value of 1 for each pair 

of i and d, the following generalized upper bound (GUB) is added: 

XXT^y < 1, Mid 
j 

Using this construction of binary variables rather than the usual “powers- 
of-two” factorization [Ref. 5:p. 190] allows discontinuity to be more easily handled. 
For example, if Xid'typical' £ {0, 3, 4, 5 } then XTidj will be defined only for j = 
3, 4, and 5. The other values will be screened out. It easy to see that j could be 
defined for any discrete set, even when several discontinuities exist. Handling this 
with the usual “powers-of-two” factorization would be difficult. The major 
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drawback to this method is that it is only practical when the number of possible j 
values is small, otherwise too many binary variables will be introduced. 

In the implementation model, we define XT idj for j = lwbnd/^-1, ... , 
upbnd/rf. This allows a resumption ship after a production break to be delivered in 
the same year as lwbnd/^-1 typical ships. 

2. Formulation 

The three constraints that were expressed mathematically in the conceptual 
model translate directly to the implementation model as follows: 

DEMAND,# X [ 2 7 XT,# + XRid' + XL,# ] = netdem/d , V i d 
d'<d j 

FISCAL^: £ [ XT idfUdp + XRidcmp + XLidclidp ] = budget^ , V p 

i d j 

CONSTRUCT;,: £ £ [ X j XT idj + XR u + XL,rf ] < sybndp , V p, 

i 0<d-p<lagi j 

provided that the following constraint is also included, 

GUB id: YxTmj ^ 1, V i d. 

j 

We now describe the implementation of the logical constraints 
mathematically. The first logical constraint is to ensure the total number of ship type i 
delivered in year d is e {0, lwbnd,# ... , upbnd,^ }. The upper bound and lower 
bound are treated separately. 

a. Upper Bound Constraint 

Using the binary variables, the upper bound constraint is written 

simply as: 

UPPER id'. Yj XT idj + XRid + XL id < upbnd,j , V i d 

j 
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b. Lower Bound Constraint 

Ensuring that the number of type i ships delivered in year d is either 
zero or greater than or equal to the lower bound lwbnd id is the most involved 
constraint in the model. This constraint needs to be stated explicitly only when 
lwbnd/tf > 2. (It holds automatically when lwbnd/^ = 1, because the variables are 
integer.) 

The lower bound constraints involve only typical and resumption 
ships, because lead ships are always built in isolation. That is, if a leadship is built, 
the lower and upper bound on total ships of its type is one. 

The inequalities designed for handling the lower bound constraint are 
dependent on knowledge of the constraint’s limited scope and on simultaneous 
enforcement of other constraints. Assume for a specific i,d'. 

1) lwbnd^/>2 

2 ) XXT^<1 

3) XL id = 0 or X/ XT idj + XR id = 0 

j 

4) XT idj = 0 for j £ {lwbnd/d-1, ... , upbnd/j) 

The first assumption is made because otherwise the lower bound 
constraint under discussion is moot. The second assumption is justified by 
appealing to the GUB constraint. The third assumption appeals to the “leadship- 
first” constraint, and the fact that the optimizer will not choose to build a leadship 
twice, since they cost more. The fourth constraint is justified simply by model 
design: we define XT idj to exist only for j e {lwbnd/^-1, ... , upbnd/j}. 
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Under these assumptions, there are eight mutually exclusive and 
collectively exhaustive cases, which can be represented in a four-by-two table. The 
rows of Table 1 correspond to possible values for the number of typical ships 
delivered. The columns correspond to possible values for the resumption ships. 
The entries of the table indicate feasibility with respect to the lower bound constraint. 

TABLE 1. FEASIBILITY WITH RESPECT TO THE LOWER BOUND CONSTRAINT. 





Numberof Resumption, 


-Ships 


Number of Tvoical ShiDs 


XRtf = 0 


XRid = 1 


X/ XT idj = 0 

j 


Feasible 


Infeasible 


X/ XT idj = lwbnd/rf-1 

j 


Infeasible 


Feasible 


X/ XT idj = lwbnd/j 
j 


Feasible 


Feasible 


X/ XT idj > lwbnd/d 
j 


Feasible 


Feasible 



Six of the eight cases are feasible and two are infeasible. A set of linear 
inequalities that correctly discriminates between the feasible and infeasible cases is: 



XT idj < XR id for j = lwbnd/tf - 1 

XR id £ 1/ XTidj 
j 



The first of these inequalities rules out the infeasible case represented in 
the second row, first column of Table 1. The second inequality rules out the other 
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infeasible case. The feasible cases do not violate either condition. Based on this 
analysis, we include the following constraints in the implementation model: 

LOWER 1 id: XTidj -XRid < 0, j = lwbnd/^ - 1 , V i d with Iwbndjj > 2 

LOWER2/^: XR/j - XxT idj < 0, V i d with lwbnd/tf > 2 

j 

c. “Leadship-First” Constraints 

The next logical constraint to be developed is one that forces a leadship 
to be purchased before any typical (or resumption) ships of its type are bought. 
This constraint applies only to new ship types. A zero/one parameter gotsome/ 
(derived from have/^ and getting,^) indicates whether any ships of type i are in 
existence or under construction. If gotsome* = 0, then a set of “leadship- first” 
constraints for ship type i must be added to the model. Without these constraints, 
the optimizer would tend to purchase typical ships without ever buying the more 
expensive leadships. 

Assuming binary values for the decision variables and satisfaction of 
the GUB constraints, the sum 

XxTj dj + XR id 

j 

will have value one or two if any non-leadships of type i are delivered in year d. 
Otherwise, this sum will be zero. 

For any given i,d , with gotsome/ = 0, the sum 

IXL,d- 

d‘<d 

will be one if a leadship of type i is delivered prior to year d. If no leadship exists in 
year d , this sum will be zero. 
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The required constraint is to prevent a non-leadship from being 

delivered prior to a leadship delivery. This can be expressed as 

y./ XT / dj + XR id ^ 2 ^,XL id' 
j d'<d 



for all i d with gotsome/ = 0. In the elastic formulation, the constraint is: 

LEADFRST/j: XxT;j» + XR/j - 2 ^XLid' < 0, V / d with gotsome/ = 0 

j d’<d 

In some Navy planning, delivery of typical ships is not scheduled 
until two years after the leadship. This affords more time for test and evaluation of 
the leadship before opening a production line. The model can easily be modified to 
enforce this scheduling constraint by redefining the leadship-first constraint as 

JjCTidj + 'XRid - 2 £XL id . < o 
j d’<d-l 

d. Production Resumption Constraints 

The next logical constraint from the conceptual model to be formulated 

mathematically is the requirement to purchase a resumption ship after a production 

break. Typical ship delivery of type i is allowed in year d only if type i is delivered 

the previous year or a resumption ship is delivered the same year. That is 

SXT idj > 1 

j 



is feasible only if 

XR id = 1 or ^XT/ d-1 j + XR/ d-1 + XL/ d-1 — 1 

j 

A constraint which enforces this relationship is: 

PRODBRK id: 'ZXTidj - XRid - Z(XT/ d -l j) - XR Z d-1 - XL/ d-1 < 0,V id 

j j 
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In order to help keep this constraint from forcing the solver to always 
lead off with a resumption unit, some early values of XT/d and XR/d are fixed using 
the value of getting/d, if gettings > 1. Since new ships will require lag / years to 
construct, the first lag/ years cannot have any new ships delivered that are not 
already in construction (and thus are included in getting/d). The actual method of 
fixing the decision variables is shown in the GAMS input file in the Appendix. 
Fixing the decision variables in this way also ensures that the calculated expenditures 
are correct, and allows the user to input the projected budget, not the projected 
budget less the amount required for ships already in construction. Additionally, if a 
leadship is being constructed the user will use a parameter leadship/d, in the same 
way as getting/^. This allows fixing the variable XL/d in the same manner. In order 
to improve solution times the planner may fix XL/d to one for some particular year d 
which is thought to be the year that the leadship will come on line. Then, by 
varying the fixed delivery year, several solutions may be obtained. 
e. Objective/Penalty Function 

The objective/penalty function is a function of all the elastic variables 
multiplied by their penalty. The penalty associated with a particular elastic variable 
should reflect the ship type and the year associated with the variable. If a constraint 
must be violated, the user would rather violate constraints associated with smaller 
ships than with very large and expensive ship. In addition, the user would rather 
violate constraints as far in the future as possible. With this in mind, the penalties are 
discounted for ship type and year. The method for discounting by ship type uses 
the concept that the larger ships are also more expensive. The penalty is multiplied 
by a ratio of the particular ship’s cost to the cost of the most expensive ship. For 
yearly discounting, the user inputs a value for the parameter discnt. The penalty 
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discount from one year to the next is (1 + discnt). If the user desires the penalties 
discounted by 5% per year, discnt will require a value of -0.05. If for some reason 
the user would rather the model violate constraints in the nearer years (if they must 
be violated) discnt will require a positive value. 

In order to allow the total penalty to be calculated, the penalty factors 
are scaled to ensure the same units are being added. For example, if the budget 
constraint is violated, the associated elastic variables need units of dollars (in order to 
add to or subtract from the budget for that year). But, the other elastic variables will 
be generally in units of ships. To keep the penalty units the same, the penalty factor 
associated with the elastic variable for budget violation is divided by the cost of the 
most expensive ship. This will yield a penalty for budget violation with units of 
penalty per ship. It should be noted that there is a negative penalty (or reward) for 
spending less than the budget. The reward for spending less than the budget by 
some amount is of course much smaller than the penalty for overspending the 
budget by the same amount. By using this reward system, if two sets of decision 
variables have the same penalty (other than the reward), the one which uses the least 
money has the lower overall penalty. 

A redundant constraint for XL/^ similar to the GUB constraint for 

XT idj is helpful in the integer enumeration. The following constraint ensures that the 

total number of leadships constructed for ship type i must be no more than one. 

MAXLEAD/: ^XLid < 1 , V /, with gotsome/ = 0 

d 

The elastic variables are Ul, VI, Y2, Z2, E3, ... , E10, 
corresponding to the constraint number, with the penalties upen, vpen, ypen, zpen. 
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pen3, ... , pen 10. The implemented formulation (with constraint numbers 
reassigned) is: 



MIN: PENALTY 

ST: 1) X [ X 0 XT id'j) + XR id’ + XL/^' ] = netdem/^ , V i d 

d’<d j 

2) X [ X O' XT/^)ct/^ + XRidcrijp + XLidclidp ] = budget;, , V p 
i d j 

3) X X [ X 0 XT idj) + XRid +XLid] < sybndn , V p 
i 0<d-p<lagi j 

4) XO XT idj) + XRid + XL id < upbnd/V/ , V / d 

j 

5) XT idj - XRid ^ 0, j = lwbnd/tf - 1 , V / d with lwbnd/j > 2 

6) XRid - X(XT/^y) < 0, V i d with lwbnd/^ > 2 

7) X(XT idj) + XRid ~ 2 X(XL/^') < 0, V / d with gotsome/ = 0 

j d'<d 

8) X(XT/^ - ) - XRid - X(XT/ d-1 j) - XR/ d-1 - XL/ d-1 ^ 0, V i d 

9) XxT/4/ <l,V/tf 
j 

10) XxL/rf < 1, V /, with gotsome/ = 0 
d 

PENALTY = X( u P en i^Ul/£/ +vpen/^Vl/^ +pen4/^E4/^ +pen5/^E5/^ ) 
id 

+ X(P en 6/rfE6 z v/ +pen7/^E7/^ +pen8/^E8/rf +pen9/</E9/</ ) 
id 

+ XCP 61110 /^ 10 /) + X(yP en p Y2 p - zpcnpZlp + pen3^E3 p ) 
i P 

D. OUTPUT 

The output from the model is displayed in three reports. An example of partial 
output reports is displayed below in Figure 1. 
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PARAMETER REPORT 1 


SHIPS BUILT VS. SHORTAGE OR EXCESS BY YEAR 






YEAR6 


YEAR6 


YEAR6 


YEAR7 


YEAR7 


’ YEAR7 


YEAR8 


YEAR8 


YEAR8 




BUILT 


SHORT 


EXCESS 


BUILT 


SHORT EXCESS 


BUILT 


SHORT 


EXCESS 


TYPE1 


LOO 


















TYPE2 














1.00 






TYPE3 








1.00 












TYPE4 




3.00 








1.00 








TYPE5 


2.00 


1.00 




4.00 


2.00 




2.00 






TYPE6 




1.00 






1.00 




1.00 






TYPE7 




2.00 






2.00 






3.00 




PARAMETER REPORT2 


EXPENDITURES VS. BUDGET BY YEAR 










YEAR3 


YEAR4 




YEAR5 


YEAR6 


YEAR7 


EXPENDED 




4160.00 


4243.00 




4329.00 


3605.00 


2278.00 


BUDGET 




4160.00 


4243.00 




4327.00 


4413.00 


4501.00 


OVERRUN 












2.00 








SAVINGS 














808.00 


2223.00 


PARAMETER REPORT3 


CONSTRAINT ELASTICITY VARIABLES 












E3 


E5 




E6 




E7 


E8 


TYPE1.YEAR9 
















0.5 


TYPE3.YEAR3 




1.0 










1.0 




TYPE4.YEAR1 






1.0 












TYPE5.YEAR5 
















0.5 


TYPE5.YEAR6 
















0.5 


TYPE6.YEAR9 




2.0 






1.0 









Figure 1. An example of partial output reports from the model. 



The first report, REPORT1, in Figure 1 provides the ship purchasing plan 
produced by the model. The columns named “BUILT” give the number of ships to 
be purchased for each ship type during a given year. The columns named 
“SHORT” and “EXCESS” give the number of ships which are short and in excess, 
respectively, of the required number of ships specified by the input data called 
need/ d- With this report the user can either implement the ship purchasing plan 
under the column “BUILT” for each year and ship type. The more logical option is 
to use that plan as the starting point and consider the other columns (i.e., “SHORT’ 
and “EXCESS”) in order to develop a long range plan that takes other factors not 
modeled into consideration. For example, if a class of ships is built and the last ship 
in the class is not built due to upper or lower bounds, then the user may want to 
order that particular ship with the last order for that ship type, or split the last order. 
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The idea is to use the model’s output as a tool for developing a long range plan, not 
to expect the model to produce the “optimal” plan. The second report shows the use 
of money and displays the budget, the amount expended, the amount of budget 
overrun, and the amount expended below the budget, for each year. The third 
report displays the values given to the constraint elasticity variables not shown in the 
first two reports for each time period and year. If the value of some constraint 
elasticity variable is not zero, then the solution displayed in the first two reports is 
actually not feasible, with respect to the constraint associated with that elasticity 
variable. Should the third report show anything other than “all zero”, the user 
should consider modifying the input values associated with elastic penalties, or 
bounds (upbndjd, lwbnd^, sybnd^, and budget^) and rerunning the model. The 
values to be modified will depend on which elastic variable had a value other than 
zero. Then, the user should report to their superiors that the stated desires are not 
feasible and provide them with values which are feasible. This information can also 
be used as a basis for negotiating new resources or mediating between conflicting 
desires. The later would normally entail performing sensitivity analysis of the 
penalties. 

E. LIMITATIONS 

In our implementation of the model, we have chosen to leave out several realistic 
features in order to make the model readily understandable. Although these features 
do represent limitations to the model, they can indeed be included at the expense of 
increased model and computational complexity. Below, we list these limitations. 

1) Except for the extra cost of a leadship or resumption ship, the model assumes 
the cost associated with a purchase is a linear function of the number of ships 
purchased. This does not allow quantity discounts, learning-curve effects, or 
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economies of scale. This deficiency can be corrected, but additional user input and 
model complexity will be required. 

2) There is no lower bound on the total number of ships that can be under 
construction in a given year. 

3) There is no cost associated with shutting down a production line. The cost of 
the variable XR id includes the cost of restarting a production line, but the cost of 
shutting down is considered negligible. Associated with this limitation is the 
assumption that the cost of restarting a production line is not a function of the 
number of years the production line has been secured. 

4) The model does not handle Ship Life Extension Program (SLEP) ships. To 
do so, constraints which force the solver to consider SLEP ships must be added to 
the model. 

5) The model shown in the Appendix has limits on the magnitude of j set at five 
and the number of years over which payments may be made for any ship type to 
five years. 
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III. COMPUTATIONAL EXPERIENCE 



The model is written and tested using the General Algebraic Modeling System, 
GAMS [Ref. 6]. GAMS is essentially a model-solver interface. It allows the model 
constraints to be written in an index-exploiting, algebraic form similar to the 
mathematical form used in scientific communication. This makes it easy to translate 
the model from the mathematical form presented in the previous chapter to the 
computer input that can be used by the GAMS interface. GAMS then translates the 
model into a form required by the solver. The available solvers include ZOOM 
[Ref. 7] and MPSX [Ref. 8]; both of which are used in this research. According to 
Reference 9 [page 3], GAMS 

1. Provides a high-level language for the compact representation of large and 
complex models 

2. Allows changes to be made in model specifications simply and safely 

3. Allows unambiguous statements of algebraic relationships 

4. Permits model descriptions that are independent of solution algorithms 

Several small scale data sets were used to validate the formulation. Initially, the 
solution was not required to be integer, and the linear programming solver MINOS 
[Ref. 10] was used. As the model neared completion, a more realistic sized data set 
and the ZOOM mixed-integer programming solver were introduced to test the 
model’s ability to generate integer solutions. However, ZOOM “is intended for 
medium- sized problems with no special structure and up to about 200 zero/one 
variables.” [Ref. 9:p. 225] Since the actual data set requires about four times this 
many zero/one variables, ZOOM quickly became inadequate with the large model. 
So, for the purpose of comparing different solvers, an intermediate sized data set 
was used. This data set allows a maximum of five ships of any one type to be 
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constructed per year (/), considers ten ship types (0, and has a ten year planning 
horizon ( d ). The model was sent to Professor Terry Harrison at Pennsylvania State 
University through BITNET, an electronic mail network worldwide. At Penn 
State, the MPSX solver was used to solve the same data set. The results are 
summarized in Figure 2. 



Input data set has : 


Typical Model has: 


10 years ( d and p ) 


335 rows of equations 


10 ship types ( i ) 


990 columns of variables 


5 ships max per year of each type (j ) 


268 discrete variables 
4891 non-zero elements 


Computer Times: 


NPS IBM 3033AP: 


IBM 3090-400: 


GAMS: 28.630 sec 


GAMS: 9.020 sec 


Solver (ZOOM): 


Solver (MPSX): 


1000 iter’s 155.150 sec 


10000 iter’s 67.800 sec 


50000 iter’s 1300.068 sec 


Solution quality: 18.9% Gap 


Solution quality: 14.6% Gap 



Figure 2. Computer time comparison for intermediate sized data set. 



The ZOOM solver has difficulty handling even this intermediate sized data set, 
showing no gain in solution quality from 1000 to 50000 iterations. MPSX, on the 
other hand, yields a better solution quality much faster and with fewer iterations. 
Several runs were made with the two solvers as the model continued to develop, 
with the same results. A larger, more realistic, data set was constructed and solved 
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with ZOOM and MPSX (via Anthony Brooke), the results are summarized in 
Figure 3. Interestingly, on this larger problem, both solvers found a better quality 
solution. 



Input data set has : 


Typical Model has: 


15 years ( d andp ) 


1158 rows of equations 


20 ship types (/' ) 


2685 columns of variables 


5 ships max per year of each type (j ) 


742 discrete variables 




16688 non-zero elements 


Computer Times: 




NPS IBM 3033AP: 


IBM 3090-400: 


GAMS: 73.520 sec 


GAMS: 20.140 sec 


Solver (ZOOM): 


Solver (MPSX): 


30000 iter’s 1458.087 sec 


24773 iter’s 644.400 sec 


Solution quality: 5.4% Gap 


Solution quality: 0.49% Gap 



Figure 3. Computer time comparison for realistic sized data set. 



In terms of solution quality, MPSX dominates ZOOM. However, ZOOM does 
give an integer solution, which is a far better starting point for developing the long 
range shipbuilding schedule than the typical “don’t build anything” starting point. 
Additionally, in ZOOM’S favor, a good solution is generally produced early on in 
the iteration count (e.g.. From Figure 3, the same solution is given after 20000 
iterations as is given at 30000 iterations). However, it seems unable to search 
through this large a problem tree and find an improving solution. ZOOM will run 
on personal computers (taking much longer than the above times), so it can be used 
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more easily with the model’s actual classified data. MPSX, on the other hand, 
generally provides a better solution in much less computer time, but requires a 
mainframe computer. 

Another solver option, which is currently being developed for use with 
GAMS, is the X-System [Ref. 4] which has solved similar problems of a much 
larger scale in relatively small computer times. Reference 1 1 develops a very similar 
model for Army helicopters with 4000 constraints, 21000 variables, 300 binary 
variables, and 100000 non-zero coefficients which is solved in about a minute when 
using the X-System (on an IBM 3033AP). 

The final option is to discard GAMS as a front end and write an independent 
solver specific to this model. This would indeed reduce the required computer time, 
but would do so at great development cost and at the expense of the GAMS 
flexibility and ease of use. Since the model will probably require solving many 
times with varied input data sets and several “what if’ scenarios, and even with 
additional constraints, the GAMS front end is too valuable to discard. It is possible, 
of course, to write a front end to the model specific solver, which is as user friendly 
as GAMS. 

Of particular value throughout this research was the GAMS “dollar operator”. 
The dollar operator is “... used for exception handling in equations.” [Ref. 9:p. 92] 
“A dollar operator within an equation is an implied if-else operation ....” [Ref. 9: 
p. 94] The dollar operator proved essential in keeping the number of variables and 
constraints down to a manageable figure. For example, consider the large data set 
whose features are shown in Figure 3. Without the dollar operator to restrict the 
variables and constraints there are 2151 constraints, 4551 variables, 2100 of them 
discrete. This is twice as many constraints and twice as many variables, so the 
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problem size is four times what it is with the dollar operator. Obviously this feature 
of GAMS is essential to the model. 

A key element of the model is the penalty factors. Setting these penalties 
correctly is very important. In this study, the penalty factors were set iteratively by 
solving the linear programming relaxation of the model. This allowed the results to 
be returned quickly, and did not use up precious computer time. To start with, all 
penalty factors were set to one, and the general penalty factor for violating logical 
constraints (epen) set to ten. Then the individual factors were raised and the general 
penalty lowered to achieve the lowest penalty (with one being the lowest factor used) 
with a solution which did not violate the logical constraints. The ship balance 
constraint (DEMAND) was allowed to be violated, and the budget allowed to be 
under spent, but the other constraints were not allowed to be violated. Examining 
the marginal value of the elastic variables and constraints was also helpful. The 
adjustment of penalties continued until the linear program produced a near integer 
solution at which point the model was transferred to an integer program solver. 
Since the units are not the same for each constraint, the penalties were scaled so that 
approximately equivalent units are added in the penalty/objective function. This 
technique proved to be useful in producing integer solutions, and at setting the 
penalties. 
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IV. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

During the course of this study, GAMS has proven to be a valuable tool in the 
model development. GAMS is both user friendly and quite flexible. It is this 
flexibility feature that allows for “what if’ type analysis. Moreover, one can also 
develop a “front end” program to interact with GAMS and thus further enhance the 
user friendliness of the overall model. 

As for the integer solvers, two solvers: MPSX and ZOOM were available 
during the study. Based on a realistically sized data set, MPSX clearly dominates 
ZOOM. However, ZOOM is available on a 386 based personal computer and 
MPSX is only available on large mainframe computers. Another solver, the X- 
System, was not interfaced with GAMS; however, based on reports of its 
performance on a similar problem, it could conceivably outperform both MPSX 
and ZOOM. 

In Chapter III, it is demonstrated that the model developed in this study does 
produce the desired result, i.e., an initial plan which analyst/planner can analyze and 
improve upon. It is cautioned that the model should not be treated as a “black-box” 
because solutions are “optimal” relative to the data provided by users. In planning, 
these data are generally rough estimates of actual values, hence the plans produced 
by the model should be treated at best as a guideline for producing a more sensible 
plan. 
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B . RECOMMENDATIONS FOR FURTHER IMPROVEMENT 

To further enhance the realism and perhaps the usefulness of the model, the 
following features can be included in the model. 

1 . Incorporate Average Ship Age 

The helicopter model developed in Reference 1 1 incorporates average ship 
age. Not only are new helicopters brought on-line, but that model also determines 
the retiring times of the current stock of helicopters. 

2. Include Shutdown Costs 

This model, as presented, does not consider the cost of shutting down the 
production line, in order to keep the level of complexity compatible with available 
solvers. A new variable representing the cost of shutting down the production line 
can be introduced. 

3 . Use Economies of Scale in Production Costs 

As pointed out in the model assumptions, economies of scale when 
purchasing ships is not allowed. Cost in this model is a linear function of the 
number of ships purchased of a given type. Since economies of scale exist, their 
introduction into the cost function could enhance the model. 

4 . Develop a User-Friendly Front End for the X-System 

As stated earlier, the X-System is an alternative solver which is not yet 
available with GAMS. By developing a front end to the X-System, one would be 
able to evaluate the advantages of the X-System over the other solvers. 

5 . Provide Graphical Displays of Solutions 

Although displaying solutions to the model numerically is adequate for 
current usage, a graphical display is more preferable to the user. 
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APPENDIX : GAMS INPUT FILE 



$OFFUPPER OFFSYMLIST OFFUELLIST OFFUELXREF OFFSYMXREF 

* Long-Range Shipbuilding Scheduling Model 

* By LT Joe Faircloth, USN, 8 August 89 (userid 1651p) 

* Based on model by Prof. Richard E. Rosenthal, 6 Sep 88 

OPTION LIMROW = 0, LIMCOL = 0, SOLPRINT = OFF; 

OPTION ITERLIM = 30000, WORK= 15000, RESLIM = 5000; 

OPTION OPTCR = 0.00, OPTCA = 1.0; 



The next area contains data which must be filled 
in by the user, or a call to a data file with it. 
The following items must be filled included: 

Sets: I, T 

Tables: HAVE, GETTING, LEADSHIP, NEED, 

COST1, COST2, COST 3, UPBND, LWBND 
Scalars: INITBUD, GROWTH, UFAC, VFAC, YFAC 
DISCNT, EPEN, P3, P4, P5, P6, 

P7, P8, P9, P10 
Parameters: UPBOUND 



*$ INCLUDE GAMS DATASET A 

* NOTE this dataset covers only 5 years, 5 ship types, max of 5 ships 

* delivered per year. This dataset is for demonstration purposes only. 

SETS 

I Ship types / TYPE1, TYPE2, TYPE 3, TYPE 4, TYPE 5 / 

D delivery years / YEAR1 * YEAR5 / 

J amount of typical units to buy / 1*5 / 

TIME time relative to year of delivery used for cost input only 
/ YR-MINUS-0, YR-MINUS-1, YR-MINUS-2, YR-MINUS-3, YR-MINUS-4 /; 

TABLE HAVE (I, D) number of each type we have from current inventory 





YEAR1 


YEAR2 


YEAR3 


YEAR4 


YEAR5 


TYPEl 


3 


3 


3 


2 


1 


TYPE 2 


2 


2 


2 


1 


1 


TYPE 3 


4 


4 


4 


4 


3 


TYPE 4 


4 


4 


3 


3 


3 


TYPE5 


0 


0 


0 


0 


0 


TABLE 


GETTING (I, D) 


units coming 


online that 


are in construction now 


* 


will 


come online 


after yearO 


but before 


lag(i)+yearl 




YEAR1 


YEAR2 


YEAR3 


YEAR4 


YEAR5 


TYPEl 




1 


2 






TYPE 2 
TYPE 3 




1 


3 
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TABLE 


LEADSHIP (I, D) 


leadships coming on line that have been started 


* 




before yearl and will come 


: on line after yearO 




YEAR! 


YEAR2 YEAR3 


YEAR4 


YEAR5 


TYPE 5 




1 






TABLE 


NEED (I, D) number of each type we want 


. in each year 




YEAR1 


YEAR2 YEAR3 


YEAR4 


YEAR5 


TYPEl 


6 


6 6 


6 


6 


TYPE 2 


5 


5 5 


5 


5 


TYPE 3 


8 


8 8 


8 


8 


TYPE 4 


9 


9 9 


9 


9 


TYPE 5 


0 


0 0 


1 


1 


TABLE 


COSTl (I, TIME) 


typical ship cost data 


in appropriate year 


* 




relative to the delivery year 






YR-MINUS-0 


YR-MINUS-1 YR-MINUS-2 


YR-MINUS-3 


YR-MINUS-4 


TYPEl 


10 




100 




TYPE 2 


20 




200 




TYPE 3 


30 


300 






TYPE 4 


40 




100 


400 


TYPE 5 


50 


500 






TABLE 


COST2 (I, TIME) 


cost data for first unit after production break 


* 




including cost of restarting production line and 


* 




the cost of the typical unit 






YR-MINUS-0 


YR-MINUS-1 YR-MINUS-2 


YR-MINUS-3 


YR-MINUS-4 


TYPEl 


10 




110 




TYPE2 


20 




220 




TYPE 3 


30 


330 






TYPE 4 


40 




150 


400 


TYPE 5 


50 


550 






TABLE 


COST 3 (I, TIME) 


leadship cost data 








YR-MINUS-0 


YR-MINUS-1 YR-MINUS-2 


YR-MINUS-3 


YR-MINUS-4 


TYPE 5 


100 




800 




TABLE 


UPBND ( I , D ) 


upper bound on the number 


of each type produced 


* 




per year if any are to be 


produced 





TYPEl 
TYPE2 
TYPE 3 
TYPE 4 
TYPE 5 



YEAR1 * YEAR15 
2 
5 
1 
4 
2 



TABLE LWBND (I, D) 



TYPEl 
TYPE2 
TYPE 3 
TYPE 4 
TYPE5 



lower bound on the number of each type produced 
per year IF ANY are to be produced 
YEAR1 * YEAR15 
2 
3 
1 
3 
1 
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PARAMETER UPBOUND(D) upper bound on the total ships under construction; 
* in year d 

UPBOUND (D) = 10; 

SCALARS INITBUD first year budget / 2000/ 



GROWTH budget growth rate as percent / 0.02/ ; 

* Set penalty factors for constraint violations 
SCALARS 

DISCNT time weighting factor for penalties /-0.05/ 

UFAC ship shortage factor per ship /2/ 

VFAC ship excess factor per ship / 2/ 

YFAC budget overrun factor per cost of largest ship /10/ 

EPEN general constraint violation penalty /10/ 

P3 penalty for violating overall construction bound /l/ 

P4 penalty for violating upper bound per ship /l/ 

P5 penalty for violating lower bound /!/ 

P6 penalty for making only one ship if LT lwbnd /l/ 

P7 penalty for not producing leadship first 111 

P8 penalty for not making a resumption unit if reqd /2/ 

P9 penalty for violating GUB bound on XT /l/ 

P10 penalty for violating GUB bound on XL /!/; 



*** End of area containing data which must be filled *** 
*** in by the user. The next area has aborts to *** 
*** ensure the data has been entered correctly. 



ABORT $ (SUM ( (I, D) $ (HAVE (I, D) LT 0,1) GT 0) 

»***=>Data entry error in table HAVE, entries may not be negative", 

HAVE; 

ABORT $(SUM((I,D)$ (GETTING (I, D) LT 0),1) GT 0) 

"***=>Data entry error in table GETTING, entries may not be negative", 
GETTING; 

ABORTS (SUM( (I, D) $( (LEADSHIP (I, D) LT 0) OR (LEADSHIP (I, D) GT 1) ) , 1) GT 0) 

"***=>Data entry error in table LEADSHIP, entries may only be zero or 

one", 

LEADSHIP; 

ABORT $ (SUM ( (I, D) $ (NEED (I, D) LT 0),1) GT 0) 

»***=>Data entry error in table NEED, entries may not be negative", 

NEED; 

ABORT $ (SUM ( (I, D) $ (NEED (I, D) LT (HAVE (I, D) +GETTING (I, D) ) ) , 1 ) EQ CARD (I) 
*CARD (D) ) "***=>NEED is satisfied by HAVE+GETTING, for every I,D", 

" There is no need to run the program, it is already optimal", 

HAVE, GETTING, NEED; 

ABORT $ (SUM ( (I, TIME) $ (COST1 (I, TIME) LT 0),1) GT 0) 

••***=>Data entry error in table COST1, all costs must be non-negative", 
COST1 ; 
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ABORT $ (SUM ( (I, TIME) $ (COST2 (I, TIME) LT 0),1) GT 0) 

"***_>Data entry error in table COST 2, all costs must be non-negative", 
COST2; 

ABORT $ (SUM ( (I, TIME) $ (COST3 (I, TIME) LT 0),1) GT 0) 

"***=>Data entry error in table COST 3, all costs must be non-negative", 
COST 3; 

ABORT $ (SUM( (I,D) $ (UPBND (I,D) LT 0),1) GT 0) 

»***=>Data entry error in table UPBND, entries may not be negative", 
UPBND; 

ABORT $ (SUM ( (I, D) $ (LWBND (I, D) LT 0),1) GT 0) 

"***=>Data entry error in table LWBND, entries may not be negative", 
LWBND; 

ABORT $ (SUM( (I, D) $ (UPBND (I, D) LT LWBND (I, D) ) , 1) GT 0) 

"***=>Data entry error in table LWBND or UPBND, LWBND must be less", 

" than or equal to UPBND, for all i,d. ", LWBND, UPBND; 

ABORT $ (INITBUD LE 0) 

"***=>Data entry error for INITBUD, entry must be positive", 

INITBUD; 

ABORT $ ( (UFAC LT 0) OR (VFAC LT 0) OR (YFAC LT 0) ) 

"***=>Data entry error in UFAC, VFAC, or YFAC, values may not be 

negative", 

UFAC, VFAC, YFAC; 

ABORT $ ( (UFAC + VFAC + YFAC) EQ 0) 

"***=>A11 penalties are zero, program is optimal as is.", 

" UFAC, VFAC, and YFAC must not all be zero.", UFAC, VFAC, YFAC; 



End of ABORTS checking user data input. 
The next areacalculates additional data 
not required to be input by the user. 



* D is used for year of delivery and P is used for year of payment 
ALIAS (D,P) ; 



PARAMETER CT(I,D,P), 
CT (I,D,P) $ (ORD (D) - 
CT (I , D, P) $ (ORD (D) - 
CT (I , D, P) $ (ORD (D) - 
CT (I , D, P) $ (ORD (D) - 
CT ( I , D , P ) $ (ORD (D ) - 

CR (I, D, P) $ (ORD (D) - 
CR (I, D, P) $ (ORD (D) - 
CR (I, D, P) $ (ORD (D) - 
CR (I, D, P) $ (ORD (D) - 
CR (I, D, P) $ (ORD (D) - 



CR(I,D,P) , CL(I,D,P) ; 



ORD (P) 


EQ 


0) 


= 


COSTl (I, "yr-minus-0"; 


ORD (P) 


EQ 


1) 


= 


COST1 (I, "yr-minus-1"; 


ORD (P) 


EQ 


2) 


= 


COSTl (I, "yr-minus-2" ; 


ORD (P) 


EQ 


3) 


= 


COSTl (I, "yr-minus-3" 


ORD (P) 


EQ 


4) 


= 


COSTl (I, "yr-minus-4": 


ORD (P) 


EQ 


0) 


= 


COST2 (I, "yr-minus-0": 


ORD (P) 


EQ 


1) 


= 


COST 2 (I, "yr-minus-1"; 


ORD (P) 


EQ 


2) 


= 


COST2 (I, "yr-minus-2"; 


ORD (P) 


EQ 


3) 


- 


COST 2 (I, "yr-minus-3"; 


ORD (P) 


EQ 


4) 


= 


COST 2 (I, "yr-minus-4"; 
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CL(I,D,P)$(ORD(D) - ORD(P) 
CL(I,D,P)$ (ORD(D) - ORD(P) 
CL (I, D, P) $ (ORD (D) - ORD(P) 
CL(I,D,P)$ (ORD(D) - ORD (P) 
CL (I, D, P) $ (ORD (D) - ORD (P) 



EQ 0) = COST3 (I, "yr-minus-0") ; 
EQ 1) = COST3 (I, "yr-minus-l" ) ; 
EQ 2) = COST3 (I, "yr-minus-2" ) ; 
EQ 3) = COST3 (I, "yr-minus-3" ) ; 
EQ 4) = COST 3 (I, "yr-minus-4" ) ; 



PARAMETER LAG (I) ; 

LAG (I) $ (COST1 (I, "yr-minus-4") 
LAG (I) $ (COST1 (I, "yr-minus-3") 
LAG (I) $ (COST1 (I, "yr-minus-2") 
LAG (I) $ (COST1 (I, "yr-minus-l") 
LAG (I) $ (COST1 (I, "yr-minus-0") 



GT 0) = 4; 

GT 0 AND LAG (I) EQ 0) = 3 
GT 0 AND LAG (I) EQ 0) = 2 
GT 0 AND LAG (I) EQ 0) = 1 
GT 0 AND LAG (I) EQ 0) = 0 



PARAMETER BUDGET (P) money available in year P to purchase ships; 
BUDGET (P)$ (ORD (P) EQ 1) = INITBUD; 

LOOP (P, BUDGET (P+1) = FLOOR( (1+GROWTH) ^BUDGET (P) ) ) ; 



PARAMETER DISCOUNT (D) discount factor for time weighting penalties; 
DISCOUNT (D) = POWER (1+DISCNT, ORD (D) -1) ; 



* Calculate the penalty values for each unit of excess, shortage, 

* and budget overrun for each type and year. Calculate all elastic 

* constraint penalties. All penalties are discounted by year and 

* relative to ship type cost. 

* so that the right hand sides of the dual equations will be integers. 
PARAMETERS 

BIGC, PRIORITY (I) ,UPEN(I,D) ,VPEN(I,D) , YPEN (D) , ZPEN (D) ,PEN3(D) , 

PEN4 (I,D) ,PEN5(I,D) ,PEN6(I,D),PEN7(I,D) ,PEN8 (I,D) ,PEN9 (I,D) ,PEN10 (I) ; 
BIGC = SMAX (I, SUM (TIME, COST1 (I, TIME) ) ) ; 

PRIORITY (I) = SUM (TIME, COST1 (I, TIME) ) / BIGC; 

UPEN (I,D) = UFAC * DISCOUNT (D) * PRIORITY(I); 

VPEN ( I , D ) = VFAC * DISCOUNT (D) * PRIORITY(I); 

YPEN (D) = YFAC * DISCOUNT (D) /BIGC; 

ZPEN (D) = YPEN (D) /10; 

PEN3 (D) = EPEN*P3*DISCOUNT (D) ; 

PEN4 (I,D) = EPEN*P4*DISCOUNT(D)*PRIORITY(I) ; 

PEN5 (I, D) = EPEN*P5*DISCOUNT (D) ^PRIORITY (I) ; 

PEN6 (I, D) = EPEN*P6*DISCOUNT(D)*PRIORITY(I) ; 

PEN7 (I, D) = EPEN*P7*DISCOUNT (D) ^PRIORITY (I) ; 

PEN8 (I, D) = EPEN*P8*DISCOUNT(D)*PRIORITY(I) ; 

PEN9 (I, D) = EPEN*P9*DISCOUNT (D) ^PRIORITY (I) ; 

PEN10(I) = EPEN*P10*PRIORITY(I) ; 



PARAMETER GOTSOME(I) equals 1 if you do not need to make a lead ship; 
GOTSOME (I) = 0 + 1$ (SUM(D,HAVE(I,D)+GETTING(I,D)+LEADSHIP(I,D) ) GT 0) ; 



PARAMETER NETDEM (I, D) totl number of i ships that must be del'd by yr d; 
NETDEM (I, D) = NEED (I, D) - HAVE(I,D); 



All data is now calculated. The next area 
defines the variables and the constraints. 



32 



VARIABLES 

XT (I , D, J) order j of type i to be delivered in year d 
XR(I,D) first one after a break in production costs more 

XL (I, D) first one of type i to come on line costs more 

U1 (I/D) shortage of type i in year d 
VI (I, D) excess of type i in year d 
Y2 (P) amount expenditure is over budget in year p 

Z2(P) amount expenditure is under budget in year p 

E3(D) elasticity variable for equation construct 

E4 (I, D) elasticity variable for equation upper 

E5 (I, D) elasticity variable for equation lowerl 

E6 (I, D) elasticity variable for equation lower2 

E7 (I, D) elasticity variable for equation leadfrst 

E8(I,D) elasticity variable for equation prodbrk 

E9(I,D) elasticity variable for equation gub 

E10(I) elasticity variable for equation maxlead 

PENTOT total penalties; 



BINARY VARIABLES XT,XR,XL; 



POSITIVE VARIABLES Ul, VI, Y2, Z2, E3, E4, E5, E6, E7, E8, E9, E10; 

*set x variables to getting (i,t) for those that occur prior to 
*yearl+lag (i) . This may prevent making a prod break type when not needed 
*and will allow the correct budget amount to be used. 

XT. FX (I, D, J) $ ( ( (GETTING (I, D-l) GE 1) OR (LEADSHIP (I, D-l) EQ 1)) 

AND (ORD(J) EQ GETTING (I, D) ) ) = 1; 

XR.FX (I, D) $ ( ( (GETTING (I, D-l) EQ 0) AND (LEADSHIP (I, D-l) EQ 0)) 

AND (GETTING (I, D) GE 1)) = 1; 

XT.FX (I,D, J) $ ( ( (GETTING (I, D-l) EQ 0) AND (LEADSHIP (I, D-l ) EQ 0)) 

AND ( (GETTING (I, D) GE 2) AND (ORD ( J) EQ GETTING (I, D) -1))) = 1; 
XL.FX (I, D) $ (LEADSHIP (I, D) EQ 1) = 1; 



Define dynamic sets of variables for use 
with dollar operators in the constraints 



SETS POS1 (I, D) , POS2 ( J, I, D) , POS3(I), POS4(I,D), POS5(I,D,J), POS6(D,P), 
POS7 (I, D) , POS8 (I,D,P) , POS9 (I,D) , POS10(I,D), POSH (I,D,P) , 

POS12 (I, D, J) , POS13 (I, D) , POS14 (I, D) , POS15 ( J, I, D) ; 

POS1 (I,D) =YES$ (ORD (D) GT LAG (I) ) ; 

POS2 ( J, I, D) =YES$ ( (ORD ( J) GE LWBND (I, D) -1) AND (ORD(J) LE UPBND (I, D) ) ) ; 
POS3 (I ) =YES$ (GOTSOME (I ) EQ 0) ; 

POS4 (I, D) =YES$( (GOTSOME (I) EQ 0) AND (ORD (D) GT LAG ( I ) ) ) ; 

POS5 (I , D, J) =YES$ (ORD ( J) EQ LWBND (I,D) -1) ; 

POS6 (D,P) =YES$ (ORD (P) LE ORD (D ) ) ; 

POS7 (I , D) =YES$ ( (ORD(D) GT LAG ( I ) ) AND (LWBND (I, D) GE 2)); 

POS8 (I , D, P) =YES$ ( (ORD(P) LTORD(D)) AND (ORD(P) GT LAG (I) ) ) ; 

POS9 (I, D) =YES$( (ORD(D) GT LAG ( I ) ) OR (GETTING (I, D) GT 0) ) ; 

POS10 (I, D) =YES$(( (GOTSOME (I) EQ 0) AND (ORD (D) GT LAG (I) ) ) 

OR (LEADSHIP (I, D) EQ 1) ) ; 

POSll (I, D, P) =YES$ ( (ORD (D) -ORD (P) GE 0) AND (ORD (D) -ORD (P) LE LAG (I)) 

AND ( (GETTING (I, D) GT 0) OR (ORD (D) GT LAG (I ) ) ) ) ; 



33 



P0S12 (I,D, J)=YES$ (( (ORD(J) GE LWBND (I, D) -1 ) AND (ORD ( J) LE UPBND (I, D) ) ) 
AND ( (ORD (D) GT LAG (I)) OR (GETTING (I, D) GT 0) ) ) ; 
POS13 (I , D) =YES$ ( (ORD (D)-l GT LAG ( I ) ) OR (GETTING (I, D-l ) GT 0) ) ; 

POS14 (I, D) =YES$ ( ( (GOTSOME (I) EQ 0) AND (ORD(D)-l GT LAG (I) ) ) 

OR (LEADSHIP (I, D-l ) EQ 1)); 

POS15 ( J, I, D) =YES$ ( ( (ORD (J) GE LWBND (I, D) -1 ) AND (ORD(J) LE UPBND (I,D) ) ) 
AND ((ORD(D)-l GT LAG (I)) OR (GETTING (I, D-l) GT 0 ) ) ) ; 



Begin listing the constraints 



EQUATIONS 

DEMAND (I, D) maintain inventory balance 
FISCAL (P) observe budget limits 

CONSTRUCT (D) prevents making more than the ship yard can make 
UPPER (I, D) total type i made in period t is less than max 

LOWERl ( I , D ) with next eqn prevents making less than lwbnd(i t) 

LOWER2 ( I , D ) with previous eqn prevents making less than lwbnd(i t) 
LEADFRST (I, D) ensures you make a first one before others if needed 
PRODBRK ( I , D ) ensures next type i after a prod break is prod break type 
GUB ( I , D ) ensures only one of the x binary types is made GUB 
MAXLEAD(I) gub bound on lead ships 
OBJDEF; 

DEMAND (I, D) $POSl (I, D) .. 

SUM(P$POS6 (D,P) , SUM(J$POS12 (I,P, J) , 

ORD ( J) *XT (I , P, J) ) 

+ XL (I, P) $POS10 (I, P) 

+ XR (I , P) $POS9 (I,P) ) 

=E= NETDEM(I,D) - U1(I,D) + V1(I,D); 

FISCAL (P) .. 

SUM((I,D), SUM ( J$POS12 (I, D, J) , 

XT (I, D, J) *ORD ( J) ) *CT (I, D, P) 

+XL (I, D) $POS10 (I , D) *CL (I, D, P) 

+XR (I, D) $POS9 (I, D) *CR(I, D, P) ) 

=E= BUDGET (P) + Y2(P) - Z2(P); 

CONSTRUCT (P) .. 

SUM (I, SUM(D$POSll (I,D,P) , 

SUM ( J$POS2 ( J, I, D) , ORD ( J) *XT (I, D, J) ) 

+ XR (I, D) + XL (I, D) $POS10 (I, D) ) ) =L= UPBOUND(P) + E3(P); 

UPPER(I,D) $POSl (I,D) .. 

SUM ( J$POS2 ( J, I, D) , XT (I, D, J) *ORD ( J) ) + XR(I,D) 

+ XL (1/ D) $POS10 (I, D) =L= UPBND (I, D) + E4(I,D); 

LOWER1 (I,D) $POS7 (I,D) .. 

SUM ( J$POS5 (I, D, J) , XT (I, D, J) ) - XR(I,D) =L= 0 + E5(I,D); 

LOWER2 (I, D) $POS7 (I, D) .. 

XR (I, D) - SUM(J$POS2(J,I / D) / XT(I,D,J)) =L= 0 + E6(I,D); 
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LEADFRST (I,D) $P0S4 (I,D) .. 

SUM(J$P0S2 ( J, I,D) , XT (I,D, J) ) + XR(I,D) 

- SUM(P$P0S8 (I,D,P) , XL (I, P) *2) 

=L= 0 + E7 (I, D) ; 

PRODBRK (I , D) $POSl (I, D) .. 

SUM( J$POS2 ( J, I, D) , 

XT (I, D, J) ) - XR(I,D) - XR(I,D-l)$POS13(I,D) 

- XL(I,D-l)$POS14(I,D) 

- SUM ( J$POS15 ( J, I, D) , XT (I,D-1, J) ) =L= 0 + E8(I,D); 

GUB (I, D) $POSl (I, D) .. 

SUM( J$POS2 ( J, I, D) , XT (I, D, J) ) =L= 1 + E9(I,D); 

MAXLEAD (I) $POS3 (I) .. 

SUM (D$POSl (I, D) , XL (I, D) ) =L= 1 + E10(I); 

OBJDEF . . 

SUM( (I,D)$POSl (I,D) , UPEN (I, D) *U1 (I, D) + VPEN (I, D) *V1 (I, D) ) 

+ SUM (P, YPEN (P) *Y2 (P) - ZPEN (P) *Z2 (P) ) + SUM(D, PEN3 (D) *E3 (D) ) 
+ SUM( (I,D) $POSl (I,D) , XRPEN*XR(I,D) + E4 (I,D) *PEN4 (I,D) 

+ E5 (I,D) *PEN5 (I/D) + E6(I,D)*PEN6(I,D) + E9 (I, D) *PEN9 (I, D) 

+ E7(I,D)*PEN7(I,D) + E8 (I, D) *PEN8 (I, D) ) 

+ SUM (I$POS3 (I) , E10 (I) *PEN10 (I) ) =E= PENTOT; 



*** All variables and constraints are now defined. Next *** 
*** send the model to the solver, then display the *** 

*** solution from the solver. *** 

★★★ ★★★ ★★★ ★★★ ★★★ ★★★ ★★★ ★★★ ★★★ ★★★ ★★★ ★★★ 



MODEL SHIPS /ALL/; 

SOLVE SHIPS USING MIP MINIMIZING PENTOT; 

PARAMETER REPORT1 (I, D, *) ships built vs. shortage or excess by year; 
REPORT1 (I,D, "BUILT") =SUM(J,XT.L (I,D, J) *ORD (J) ) +XR.L(I,D) +XL.L(I,D); 
REPORT1 (I,D, "SHORT") = U1.L(I,D); 

REPORT1 (I,D, "EXCESS" )= V1.L(I,D) ; 

OPTION REPORT1 : 2:1:2; 

DISPLAY REPORT 1; 



PARAMETER REPORT2(*,P) 
REPORT2 ( "EXPENDED " , P ) 
REPORT2 ("BUDGET" ,P) 
REPORT2 ( "OVERRUN" , P ) 
REPORT2 ( " SAVINGS " , P ) 
OPTION REPORT 2 : 2 ; 
DISPLAY REPORT2; 



expenditures vs. budget by year; 
= BUDGET (P) - Z2(P) + Y2(P); 

= BUDGET (P); 

= Y2.L(P); 

= Z2.L (P) ; 
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PARAMETER REPORT 3 constraint elasticity variables; 
REPORT3 (I,D, "E3" ) $ (ORD (I) EQ 1) = E3.L(D); 



REPORT3 (I, D, "E4” ) 
REPORT3 (1/ D, "E5" ) 
REPORT3 (I, D, "E6") 
REPORT3 (I, D, ”E7" ) 
REPORT3 (I, D, "E8" ) 
REPORT3 (I/D, "E9" ) 



E4.L(I,D) ; 
= E5.L(I,D) ; 
= E6.L(I,D) ; 
= E7.L(I,D) ; 
= E8.L(I,D) ; 
= E9.L(I,D) ; 



REPORT3 (I/D, "E10") $ (ORD (D) EQ 1) = EIO.L(I); 



OPTION REPORT3 : 1 : 2 : 1 ; 
DISPLAY REPORT 3; 
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